Wie kann ein Unternehmen die Vorteile der Cloud nutzen, ohne die Kontrolle über kritische Daten, Systeme und Betriebsprozesse aus der Hand zu geben?

Der Begriff „digitale Souveränität“ beschreibt dabei nicht den Rückzug aus der Cloud, sondern die Fähigkeit, digitale Technologien selbstbestimmt, kontrolliert, rechtskonform und resilient einzusetzen.
Es geht nicht darum, Innovation zu verhindern oder moderne Plattformen zu meiden. Vielmehr sollen Organisationen Cloud-Technologien so nutzen, dass sie jederzeit wissen, wo ihre Daten liegen und wer darauf zugreifen kann. Ebenso muss klar sein, welche rechtlichen Rahmenbedingungen gelten und wie geschäftskritische Dienste auch unter schwierigen Bedingungen weiterbetrieben werden können.

https://open.spotify.com/episode/0rvDRDChFKk0fHodF4KeO2?si=7E1pHzL2RqSlJod3ZFGbXQ&nd=1&dlsi=1fa1faaaf49f44c3

Microsoft reagiert auf diese Anforderungen mit dem Konzept der „Microsoft Sovereign Cloud“. Dieses Portfolio umfasst unterschiedliche Modelle und technische Bausteine, mit denen Unternehmen und öffentliche Organisationen ihre Cloud-Strategie an Souveränitätsanforderungen ausrichten können. Dabei stehen nicht nur einzelne Technologien im Vordergrund, sondern das Zusammenspiel aus Governance, Security, Datenkontrolle, Schlüsselmanagement, Confidential Computing, Resilienz, lokalen Betriebsmodellen und Partnerstrukturen.
Für Unternehmen bedeutet das: Die zentrale Herausforderung besteht nicht darin, sich für oder gegen die Cloud zu entscheiden. Die eigentliche Herausforderung liegt vielmehr darin, das richtige Cloud-Modell für den jeweiligen Schutzbedarf, die regulatorischen Anforderungen und die strategischen Ziele zu wählen.
Genau hier entsteht Beratungs- und Umsetzungsbedarf – insbesondere für Organisationen, die die Cloud als geschäftskritische Plattform nutzen wollen, aber gleichzeitig hohe Anforderungen an Compliance, Betriebssicherheit und Kontrolle haben.

Was bedeutet digitale Souveränität im Cloud-Kontext?

Digitale Souveränität wird häufig verkürzt als reine Datenlokalität verstanden. In der Praxis ist dieser Begriff jedoch wesentlich umfassender. Es reicht nicht aus, Daten in einer bestimmten Region zu speichern. Eine souveräne Cloud-Strategie muss mehrere Dimensionen berücksichtigen (Abb. 1).

Abb. 1: Dimensionen der Cloud-Strategie

Recht und Compliance

Unternehmen müssen sicherstellen, dass ihre Cloud-Nutzung mit den geltenden gesetzlichen und regulatorischen Anforderungen vereinbar ist. In Europa zählen dazu insbesondere Datenschutz, branchenspezifische Vorgaben, Anforderungen an die Nachvollziehbarkeit, Aufbewahrungspflichten sowie teilweise auch nationale Anforderungen an kritische Infrastrukturen. Für international tätige Unternehmen kann es zudem zu Konflikten zwischen verschiedenen Rechtsräumen kommen. Eine souveräne Cloud-Architektur muss daher Transparenz über Datenflüsse, Betriebsprozesse und Zugriffsmöglichkeiten schaffen.

Cyber-Security

Souveränität bedeutet nicht nur Kontrolle, sondern auch Schutz. Unternehmen benötigen Mechanismen, um ihre Systeme und Daten gegen Cyberbedrohungen zu verteidigen. Dazu gehören Identitäts- und Zugriffskontrollen, Verschlüsselung, Netzwerksegmentierung, Monitoring, Schwachstellenmanagement, Zero-Trust-Prinzipien und automatisierte Sicherheitsrichtlinien. Gerade in souveränen Cloud-Szenarien ist Sicherheit kein Zusatz, sondern ein integraler Bestandteil des Architekturdesigns.

Datenkontrolle

Beim Thema Datenkontrolle geht es um die Frage, wer technisch, organisatorisch und operativ Zugriff auf Daten erhalten kann. Datenkontrolle umfasst Verschlüsselung, Schlüsselmanagement, Zugriffsgenehmigungen, Protokollierung, Administrationsmodelle und Governance-Richtlinien.
Besonders wichtig ist dabei die Unterscheidung zwischen der Kontrolle über Daten und der Kontrolle über Schlüssel. Wer die kryptografischen Schlüssel kontrolliert, kontrolliert in vielen Szenarien auch die effektive Zugriffsmöglichkeit auf geschützte Informationen.

Operative Resilienz

Unternehmen müssen ihre geschäftskritischen Abläufe auch bei Störungen aufrechterhalten können. Das betrifft technische Ausfälle ebenso wie regulatorische, geopolitische oder organisatorische Risiken.
Resilienz bedeutet deshalb nicht nur Backup und Disaster Recovery, sondern auch die Fähigkeit, Betriebsmodelle so zu gestalten, dass kritische Services kontrollierbar, wiederherstellbar und im Extremfall auch unabhängig betreibbar bleiben.

Innovationsfähigkeit

Digitale Souveränität darf keine Innovationsbremse sein. Im Gegenteil: Eine moderne, souveräne Cloud-Strategie soll es Organisationen ermöglichen, neue Technologien wie künstliche Intelligenz, Analytics, Automatisierung, Plattformdienste und moderne Entwicklungsmodelle sicher und regelkonform zu nutzen. Souveränität bedeutet daher nicht Isolation, sondern kontrollierte Handlungsfähigkeit.
„Microsoft Sovereign Cloud“ – ein Portfolio statt einer Einzellösung
Microsoft positioniert die „Sovereign Cloud“ nicht als einzelnes Produkt, sondern als Portfolio unterschiedlicher Modelle und Technologien. Dieses Portfolio soll Organisationen dabei unterstützen, je nach Anforderung die passende Balance zwischen Public-Cloud-Innovation, lokaler Kontrolle, regulatorischer Sicherheit und nationaler Souveränität zu finden (Abb. 2).

Abb. 2: Drei Cloud-Modelle adressieren unterschiedliche Ausgangssituationen

Wichtig hierbei ist, dass die Modelle nicht als einfache Reifegradstufen zu verstehen sind. So ist die „National Partner Cloud“ nicht automatisch besser als die „Sovereign Public Cloud“. Vielmehr unterscheiden sich die Modelle in Bezug auf Zielsetzung, Schutzbedarf, Betriebsmodell, Innovationsgrad und regulatorische Tiefe.
Ein Unternehmen mit starkem Fokus auf KI, Analytics und global skalierbaren Plattformdiensten wird andere Anforderungen haben als eine Behörde mit Geheimhaltungsanforderungen oder ein Betreiber kritischer Infrastruktur mit Offlineanforderungen.
Die Wahl des richtigen Modells ist daher eine strategische Architekturentscheidung. Sie sollte nicht ausschließlich aus technologischer Sicht getroffen werden. Entscheidend sind der fachliche Kontext, die Risikobewertung, die regulatorischen Anforderungen, die bestehende IT-Landschaft, die Betriebsfähigkeit der Organisation und die langfristige Cloud-Strategie.

Sovereign Public Cloud – Innovation mit zusätzlichen Souveränitätskontrollen

Die Sovereign Public Cloud baut auf der Microsoft Public Cloud auf und erweitert diese um Mechanismen, die Souveränitätsanforderungen unterstützen. Sie ist besonders relevant für Unternehmen, die

• moderne Azure-Dienste,
• Skalierung,
• Automatisierung,
• künstliche Intelligenz,
• Plattformservices

nutzen möchten, dabei aber zusätzliche Governance und Kontrollmechanismen benötigen.
Ein zentrales Element in diesem Modell sind die „Sovereign Landing Zones“ (Abb. 3). Sie bilden die technische und organisatorische Grundlage für eine strukturierte Cloud-Nutzung.

Abb. 3: Sovereign Landing Zones

Eine Landing Zone umfasst typischerweise:

• Managementgruppen
• Subscriptions
• Richtlinien
• Netzwerkarchitekturen
• Identitäts- und Berechtigungsmodelle
• Logging- und Monitoringstrukturen
• Sicherheitsvorgaben
• Automatisierungsmechanismen

In souveränen Szenarien kommen zusätzliche Anforderungen hinzu, etwa Datenresidenz, die Einschränkung bestimmter Dienste, Richtlinien für erlaubte Regionen, Vorgaben für Verschlüsselung, Anforderungen an das Key-Management und spezielle Kontrollmechanismen für Administrationszugriffe.
Der Vorteil eines solchen Ansatzes liegt darin, dass Governance nicht nachträglich ergänzt wird, sondern von Beginn an in die Plattform integriert ist. Viele Cloud-Probleme entstehen, weil Organisationen Workloads schnell bereitstellen, ohne vorher klare Standards zu definieren. Später müssen Berechtigungen, Netzwerke, Policies (Richtlinien), Namenskonventionen, Sicherheitsfunktionen und Kostenstrukturen korrigiert werden. Eine Landing Zone vermeidet diesen Wildwuchs, indem sie eine kontrollierte Ausgangsbasis schafft.
Für souveräne Anforderungen ist dieser präventive Ansatz besonders wichtig. Wenn Daten erst einmal in falschen Regionen, falschen Services oder unzureichend geschützten Umgebungen verarbeitet wurden, ist eine nachträgliche Korrektur komplex, teuer und risikobehaftet. Sovereign Landing Zones helfen, solche Fehler durch technische Leitplanken bereits im Voraus zu verhindern.

Technisch können Policies beispielsweise erzwingen, dass Ressourcen nur in bestimmten Regionen erstellt werden dürfen. Sie können sicherstellen, dass Storage Accounts verschlüsselt sind, Diagnosedaten korrekt weitergeleitet werden, bestimmte Netzwerkpfade gesperrt sind oder nur freigegebene Ressourcentypen verwendet werden dürfen.
Managementgruppen ermöglichen eine hierarchische Struktur, über die zentrale Governance auf unterschiedliche Geschäftsbereiche, Länderorganisationen oder Workload-Klassen angewendet werden kann. Damit wird die Landing Zone zur Schnittstelle zwischen Strategie und Umsetzung.
Die Geschäftsanforderung „Unsere Daten müssen kontrolliert und compliant verarbeitet werden“ wird in konkrete technische Regeln übersetzt. Genau diese Übersetzungsleistung ist entscheidend, weil digitale Souveränität andernfalls ein abstrakter Begriff bleibt.
Ein weiterer wichtiger Baustein ist das „Azure Key Management“. In nahezu jeder Diskussion über Cloud-Souveränität taucht die Frage auf: „Wer kontrolliert die Schlüssel?“ Diese Frage ist zentral, weil Verschlüsselung allein nicht automatisch Souveränität schafft. Entscheidend ist zunächst, wer Zugriff auf das Schlüsselmaterial hat und wie Schlüssel erzeugt, gespeichert, rotiert, gesichert und gelöscht werden. Ebenso wichtig ist, ob der Kunde die effektive Kontrolle über die daraus entstehenden kryptografischen Abhängigkeiten behält.

Abb. 4: Azure Key Management

Microsoft bietet in diesem Bereich mehrere Dienste an, die in Abbildung 4 zu sehen sind. Die Dienste unterscheiden sich hinsichtlich Zielsetzung, Schutzbedarf, Betriebsmodell und Grad der Schlüsselsouveränität:

Azure Key Vault ist eine Platform-as-a-Service-Lösung (PaaS) zur Verwaltung von Schlüsseln, Secrets und Zertifikaten. Für viele Unternehmensszenarien stellt dieser Dienst eine gute Grundlage dar, insbesondere wenn Anwendungen Secrets sicher abrufen oder Verschlüsselungsschlüssel zentral verwaltet werden sollen. Die Premiumvariante von Azure Key Vault bietet HSM-gestützten Schutz (Hardware Security Module) und damit ein höheres Sicherheitsniveau. Jedoch muss im souveränen Kontext genau bewertet werden, ob dieses Modell ausreicht oder ob stärkere Anforderungen an die Schlüsselsouveränität bestehen.
Azure Key Vault Managed HSM bietet ein noch stärker isoliertes Modell für Kunden, die dedizierte HSM-Funktionalität benötigen. Es ist für Szenarien geeignet, in denen Schlüsselmaterial besonders geschützt und stärker kundenkontrolliert verwaltet werden soll. Für Organisationen mit hohen regulatorischen Anforderungen kann das ein wesentliches Entscheidungskriterium sein.
Azure Cloud HSM ist für Szenarien konzipiert, in denen Organisationen eine besonders hohe Kontrolle über HSM-basierte Schlüsselverarbeitung benötigen. Dieser Ansatz kann in IaaS-nahen Architekturen, bei Legacy-Workloads oder bei speziellen Compliancevorgaben relevant sein.
Azure Payment HSM ist ein spezialisierter Dienst für den Zahlungsverkehr und die PIN-Verarbeitung.

Es gibt also nicht „das eine“ Key-Management-Produkt, sondern je nach Schutzbedarf und Use Case unterschiedliche Optionen. Aus Architektursicht sollte die Auswahl des Key Managements nicht isoliert erfolgen. Sie muss mit Datenklassifizierung, Workload-Kritikalität, regulatorischen Anforderungen, Betriebsmodell, Notfallprozessen und Lifecycle-Management abgestimmt werden. Ein hochsicheres HSM nützt beispielsweise wenig, wenn Rollen falsch vergeben sind, Notfallzugriffe unklar sind oder die Schlüsselrotation nicht organisatorisch beherrscht wird.
Ein ausgereiftes Key-Management-Konzept umfasst daher mehrere Ebenen. Erst das Zusammenspiel all dieser Ebenen schafft echte Datensouveränität:

• technische Schlüsselablage
• Rollen und Berechtigungsmodell
• Protokollierung
• Genehmigungsprozesse
• Rotation
• Backup
• Wiederherstellung
• Trennung von Administrationsrollen
• regelmäßige Überprüfung

Ein weiterer technischer Eckpfeiler ist „Azure Confidential Computing“ (Abb. 5). Bei der klassischen Verschlüsselung werden Daten typischerweise sowohl im Ruhezustand als auch während der Übertragung geschützt. Daten im Ruhezustand werden beispielsweise auf Datenträgern, in Datenbanken oder Storage-Systemen verschlüsselt. Daten während der Übertragung werden durch Protokolle wie TLS geschützt. Auf Daten während der aktiven Verarbeitung wurde lange Zeit weniger der Fokus gelegt. Genau hier setzt Confidential Computing an.

Abb. 5: Azure Confidential Computing

Beim Confidential Computing werden Daten in einer hardwarebasierten, vertrauenswürdigen Ausführungsumgebung verarbeitet, die sie auch während der Berechnung schützt. Dadurch können sensible Workloads ausgeführt werden, ohne dass die zugrunde liegende Infrastruktur vollständige Einsicht in die verarbeiteten Daten erhält.
Für souveräne Cloud-Szenarien ist dieser Ansatz besonders relevant. Viele Organisationen akzeptieren die Speicherung oder Übertragung von Daten in der Cloud unter bestimmten Bedingungen, haben aber Bedenken bei der Verarbeitung hochsensibler Daten. Dazu zählen beispielsweise Gesundheitsdaten, Finanzdaten, vertrauliche Forschungsdaten, personenbezogene Daten, Daten aus kritischer Infrastruktur oder geheimhaltungsbedürftige Analysen. Confidential Computing kann dabei helfen, solche Workloads in moderne Cloud-Architekturen zu integrieren, ohne Schutzanforderungen zu vernachlässigen.
Auch im Bereich der künstlichen Intelligenz gewinnt Confidential Computing zunehmend an Bedeutung. KI-Modelle benötigen in der Regel große Datenmengen und eine leistungsfähige Infrastruktur. Gleichzeitig sollen sensible Daten nicht unkontrolliert offengelegt werden. Vertrauliche Ausführungsumgebungen können dazu beitragen, die Datenverarbeitung, das Modelltraining und Inferenzszenarien sicherer zu gestalten.
Wichtig ist jedoch: Confidential Computing ersetzt keine vollständige Sicherheitsarchitektur. Es handelt sich vielmehr um einen zusätzlichen Schutzmechanismus, der in ein Gesamtkonzept eingebettet werden muss. Identitätskontrolle, Netzwerkdesign, Secrets Management, Logging, Schwachstellenmanagement, sichere Softwareentwicklung und Governance bleiben weiterhin notwendig.

In souveränen Cloud-Szenarien ist allerdings nicht nur entscheidend, wo Daten gespeichert werden, sondern auch, wer unter welchen Bedingungen Zugriff auf Systeme erhalten kann. Gerade operative Zugriffe durch Provider, Supportteams oder privilegierte Administratoren sind für regulierte Organisationen besonders sensibel.
Genau diese Herausforderung greift „Data Guardian“ auf und bringt zusätzlich ein Governance- und Transparenzelement in souveräne Cloud-Szenarien (Abb. 6). Das Konzept sieht vor, dass Zugriffe auf sensible Infrastrukturen regional überwacht und genehmigt werden. Dabei kommen explizite Genehmigungsworkflows zum Einsatz, die eine Human-in-the-Loop-Entscheidung verlangen, bevor operative Maßnahmen durchgeführt werden. Das bedeutet, dass ein Zugriff nicht allein technisch erfolgt, sondern kontrolliert, nachvollziehbar und genehmigt.

Abb. 6: Data Guardian

Zusätzlich spielt die manipulationssichere Protokollierung eine zentrale Rolle. Alle genehmigten Zugriffssitzungen werden unveränderlich aufgezeichnet. Dadurch entsteht Transparenz darüber, welche operativen Maßnahmen durchgeführt wurden, wer sie genehmigt hat und in welchem Kontext sie stattfanden. Diese Nachvollziehbarkeit ist besonders wertvoll für Audits, behördliche Überprüfungen und interne Complianceprozesse.
Data Guardian unterstützt damit eine wesentliche Anforderung der digitalen Souveränität. Im Zweifel reicht es nicht, wenn Organisationen nur behaupten, dass Zugriffe kontrolliert waren; sie müssen es auch belegen können. Die Kombination aus Genehmigung, regionaler Aufsicht, Protokollierung und Rückverfolgbarkeit schafft hierfür eine wichtige Grundlage.

Sovereign Private Cloud – Kontrolle und Autonomie im lokalen Betrieb

Während die Sovereign Public Cloud auf der Microsoft Public Cloud mit zusätzlichen Souveränitätskontrollen basiert, verfolgt die „Sovereign Private Cloud“ einen anderen Ansatz. Hier rücken lokale Betriebsmodelle, physische Kontrolle, Offlinefähigkeit und Autonomie stärker in den Vordergrund.
Ein zentraler Bestandteil dieses Modells ist Azure Local. Damit können Organisationen geschäftskritische Infrastrukturen mit Azure-Governance und -Policies betreiben, ohne zwingend dauerhaft an die Public Cloud angebunden zu sein. Das ist besonders relevant für Szenarien, in denen Daten und Workloads lokal verbleiben müssen oder in denen eine Verfügbarkeit auch bei eingeschränkter Konnektivität sichergestellt sein soll.
Die Sovereign Private Cloud eignet sich daher besonders für Organisationen mit hohen Anforderungen an Resilienz und Autonomie. Typische Einsatzfelder sind kritische Infrastrukturen, industrielle sowie militärische oder behördliche Umgebungen. Hinzu kommen Standorte mit eingeschränkter Konnektivität und Workloads, die aus regulatorischen Gründen nicht in einer Public-Cloud-Region betrieben werden dürfen.
Ein weiterer Aspekt ist „Microsoft 365 Local“. Damit sollen zentrale Produktivitäts-Workloads vollständig innerhalb einer souveränen Azure-Local-Umgebung ausgeführt werden können. Für Organisationen mit besonders hohen Anforderungen an Datenhaltung, Identität, Kommunikation und Kollaboration kann das ein entscheidender Faktor sein.
Speziell „Foundry Local“ adressiert lokale KI-Szenarien in souveränen Offline-Set-ups. Das ist strategisch bedeutsam, da künstliche Intelligenz zunehmend in geschäftskritische Prozesse integriert wird. Wenn KI-Funktionen lokal und kontrolliert betrieben werden können, entstehen neue Möglichkeiten für Organisationen, die Innovation nutzen wollen, aber Daten oder Betriebsprozesse nicht in eine Public-Cloud-Umgebung verlagern dürfen.
Ein weiterer Unterschied zur Public Cloud liegt in der Identitätssouveränität. In Private-Cloud-Szenarien können Identitäts- und Zugriffsmanagement lokal betrieben werden. Dadurch erhalten Organisationen mehr Kontrolle über IAM-Prozesse (Identity and Access Management), Authentifizierung, Autorisierung und Abhängigkeiten. Das ist insbesondere in vollständig oder teilweise getrennten Umgebungen ein wesentlicher Faktor.
Auch die Telemetriekontrolle spielt eine wichtige Rolle. Diagnose- und Telemetriedaten können innerhalb der kontrollierten Umgebung des Kunden oder Partners verbleiben. Für Organisationen, die besonders sensibel auf Betriebsdaten, Metadaten oder Diagnosedaten reagieren, ist das ein zusätzlicher Vorteil.
Die Sovereign Private Cloud ist jedoch nicht automatisch für jedes Unternehmen die beste Wahl. Sie bietet mehr Kontrolle und Autonomie, bringt aber auch höhere Anforderungen mit sich, beispielsweise an:

• Betrieb
• Hardware
• Lifecycle-Management
• Kapazitätsplanung
• lokale Expertise
• Verantwortlichkeit

Während die Public Cloud viele Betriebsaufgaben abstrahiert, müssen lokale Modelle stärker geplant und betrieben werden.

National Partner Cloud – für hochregulierte und staatliche Szenarien

Das dritte Modell ist die „National Partner Cloud“. Es richtet sich insbesondere an Behörden, öffentliche Auftraggeber und Organisationen mit sehr hohen Anforderungen an Sicherheit, Geheimhaltung und lokalisierte Betriebsverantwortung. Aktuell werden Delos in Deutschland und Bleu in Frankreich als Anbieter genannt.
Der zentrale Gedanke dieses Modells ist, dass der Cloud-Betrieb durch lokal beziehungsweise europäisch ansässige und autorisierte Betreiberstrukturen erfolgt. Damit wird nicht nur die technische Plattform betrachtet, sondern auch die operative Kontrolle. Für staatliche oder sicherheitskritische Szenarien ist diese operative Souveränität ein entscheidendes Kriterium.
Ein weiterer Aspekt ist das „European Digital Resilience Commitment“. Es geht über technische Kontrollen hinaus und adressiert vertragliche sowie geopolitische Resilienz. Sollte der Cloud-Betrieb aus geopolitischen Gründen beeinträchtigt werden, sollen Partnerschaften und europäische Infrastrukturen seine Fortführung ermöglichen. Dieser Ansatz erweitert die digitale Souveränität um eine strategische Absicherungsebene.
Auch in der National Partner Cloud spielt Data Guardian eine große Rolle. Damit soll sichergestellt werden, dass ausschließlich europäische bzw. entsprechend autorisierte Mitarbeiter den Zugriff auf sensible Infrastrukturen genehmigen und überwachen können.
Die National Partner Cloud eignet sich vor allem dort, wo Public-Cloud-Innovation allein nicht ausreicht und nationale Anforderungen an Betrieb, Zugriff, Zertifizierung und Sicherheitsüberprüfung bestehen. Sie ist nicht als Standardmodell für alle Unternehmen zu verstehen, sondern als spezialisiertes Betriebsmodell für Szenarien mit besonderem Schutzbedarf.

Das richtige Modell wählen – eine Risikoentscheidung

Die Wahl des richtigen Modells ist nicht primär eine Technologieentscheidung, sondern vor allem eine Risikoentscheidung. Die Auswahl zwischen

• Sovereign Public Cloud,
• Sovereign Private Cloud und
• National Partner Cloud

sollte nicht primär anhand einzelner Produkte erfolgen. Entscheidend ist der fachliche und regulatorische Kontext (Abb. 7).

Abb. 7: Modellauswahl als Technologieentscheidung bzw. Risikoentscheidung

Wenn Innovation und Skalierung im Vordergrund stehen, etwa für KI- und Analytics-Workloads, Azure OpenAI, Serverless-Architekturen oder moderne Anwendungsentwicklung, ist die Sovereign Public Cloud oft die naheliegende Wahl. Sie bietet Zugriff auf das breite Portfolio der Microsoft Public Cloud, ergänzt um Souveränitätskontrollen wie Landing Zones, Key Management, Confidential Computing und Data Guardian.
Wenn der Fokus auf Resilienz und Autonomie liegt, etwa bei kritischer Infrastruktur oder stark lokalisierten Betriebsanforderungen, kann die Sovereign Private Cloud die bessere Wahl sein. Hier stehen lokale Datenhaltung, physische Kontrolle, Offline- oder Air-Gap-Fähigkeit sowie lokale Betriebsverantwortung stärker im Mittelpunkt.
Wenn hingegen nationale Sicherheit, höchste Geheimhaltungsanforderungen oder spezifische Behördenvorgaben im Vordergrund stehen, ist die National Partner Cloud das passende Modell. Hier zählen nationale Betreiberstrukturen, sicherheitsüberprüftes Personal, besondere Zertifizierungen und eine stärkere operative Souveränität.
In der Praxis werden Unternehmen häufig hybride Zielbilder entwickeln. Nicht jeder Workload erfordert dasselbe Maß an Souveränität. Ein allgemeines Collaboration-System, eine Analytics-Plattform, ein ERP-System, ein KI-Use-Case und eine kritische Steuerungsanwendung können völlig unterschiedliche Anforderungen haben.

Deshalb sollte die Cloud-Strategie nicht pauschal ein einziges Modell vorgeben, sondern die Workloads klassifizieren und je nach Schutzbedarf die geeignete Zielarchitektur definieren. Eine sinnvolle Bewertungsmethodik beginnt mit einer Datenklassifizierung und Risikoanalyse:

• Welche Daten werden verarbeitet?
• Welche regulatorischen Anforderungen gelten?
• Wer darf Zugriff haben?
• Welche Abhängigkeiten bestehen?
• Welche Ausfallzeiten sind akzeptabel?
• Welche Innovationen werden benötigt?
• Welche Betriebsfähigkeiten sind intern vorhanden?

Erst danach sollte entschieden werden, welches Cloud-Modell geeignet ist.

Warum Unternehmen ein „Cloud Center of Excellence“ benötigen

Technologie allein reicht nicht aus, um digitale Souveränität erfolgreich umzusetzen. Organisationen benötigen Strukturen, Rollen, Prozesse, Standards und Governance. Genau hier kommt ein Cloud Center of Excellence, kurz CCoE, ins Spiel (Abb. 8).

Abb. 8: Cloud Center of Excellence

Ein CCoE bündelt die Cloud-Kompetenz eines Unternehmens organisatorisch und funktional. Es definiert Leitlinien, Best Practices, Architekturstandards, Governance-Modelle, Sicherheitsvorgaben, Automatisierungsmuster, Kostenkontrollmechanismen und Betriebsprozesse. Gleichzeitig unterstützt es Fachbereiche und IT-Teams dabei, Cloud-Services sicher und effizient zu nutzen.
Funktional kann ein CCoE technisch, businessorientiert und serviceorientiert ausgestaltet sein:

Die technische Ausprägung fokussiert sich auf Architekturstandards, Landing Zones, die Plattform, Automatisierung und Security.
Die businessorientierte Ausprägung behandelt Kostenkontrolle, Cloud-Business-Modelle, Governance und Changemanagement.
Die serviceorientierte Ausprägung stellt ein standardisiertes, effizientes und hochwertiges Serviceangebot bereit.

Gerade im Kontext souveräner Cloud-Architekturen ist ein CCoE von besonderem Wert. Denn Souveränität erfordert konsistente Entscheidungen in Bezug auf Regionen, Datenklassifizierung, Schlüsselmanagement, Netzwerkarchitektur, Identität, Zugriff, Logging, Monitoring und Compliance. Werden diese Entscheidungen dezentral und uneinheitlich getroffen, entstehen Risiken und Ineffizienzen. Ein CCoE sorgt hingegen für Standardisierung und Wiederverwendbarkeit.
Ein weiterer Vorteil ist die Geschwindigkeit. Viele Unternehmen glauben, Governance würde Cloud-Projekte verlangsamen. In der Praxis ist jedoch oft das Gegenteil der Fall. Wenn Standards, Landing Zones, Sicherheitsvorgaben und Betriebsprozesse bereits definiert sind, können neue Projekte schneller starten. Die Teams müssen nicht jedes Mal Grundsatzentscheidungen neu treffen, sondern können auf bewährte Muster zurückgreifen.
Ein CCoE unterstützt außerdem den kulturellen Wandel. Cloud-Transformation umfasst nicht nur die technische Migration. Sie verändert auch Verantwortlichkeiten, Finanzierungsmodelle, Betriebsprozesse, Sicherheitskonzepte und die Zusammenarbeit zwischen IT und Business. Change- und Innovationsmanagement sind daher zentrale Bestandteile eines erfolgreichen Cloud-Modells.

„Cloud Adoption Framework“ als methodischer Rahmen

Das Microsoft Cloud Adoption Framework bietet einen strukturierten Ansatz, um die Cloud-Transformation planbar und kontrolliert umzusetzen (Abb. 9).

Abb. 9: Microsoft Cloud Adoption Framework (Quelle: learn.microsoft.com)

In der Strategiephase werden Motivation, Business-Outcomes, Business-Justification und Projektpriorisierung geklärt. Für souveräne Cloud-Projekte ist diese Phase besonders wichtig, weil die Zielsetzung klar definiert werden muss.

• Geht es um Innovation?
• Um Compliance?
• Um Kostenoptimierung?
• Um Resilienz?
• Um Modernisierung?
• Oder um eine Kombination dieser Ziele?

In der Planungsphase werden digitale Assets erfasst, organisatorische Abstimmungen durchgeführt, Skill Gaps identifiziert und ein Cloud-Adoption-Plan erstellt. Für souveräne Szenarien sollte hier zusätzlich eine Daten- und Workload-Klassifizierung erfolgen. Da nicht jeder Workload dasselbe Souveränitätsniveau benötigt, ist eine differenzierte Planung notwendig.
In der Ready-Phase wird die technische Plattform vorbereitet. Dazu gehören: Azure Setup Guide, erste Landing Zones, Erweiterung der Landing Zone und Best Practices. Für souveräne Anforderungen ist diese Phase entscheidend, weil hier Governance, Security, Netzwerk, Identität, Logging und Richtlinien technisch verankert werden.
In der Adopt-Phase erfolgt die Migration oder Innovation. Migration umfasst die Bewertung, Bereitstellung, Optimierung, Absicherung und Verwaltung bestehender Workloads. Innovation bezieht sich auf neue digitale Lösungen, moderne Entwicklungsmodelle und datengetriebene Services. In souveränen Cloud-Szenarien müssen beide Ansätze mit den Compliance- und Sicherheitsanforderungen abgestimmt werden.
„Governance, Manage und Secure“ bilden den dauerhaften Rahmen. Governance umfasst Methodik, Benchmarks, ein initiales Best-Practice-Modell und den Governance-Reifegrad. Manage umfasst Business-Commitments, Operations Baseline und Operations Maturity. Für digitale Souveränität sind diese Disziplinen unverzichtbar, weil Souveränität kein einmaliges Projekt ist, sondern kontinuierlich betrieben und überprüft werden muss.

Fazit

Digitale Souveränität und Cloud schließen einander nicht aus. Im Gegenteil: Eine moderne, souveräne Cloud-Strategie ermöglicht es Unternehmen, Innovation und Kontrolle miteinander zu verbinden. Microsoft stellt mit der Sovereign Cloud ein breites Portfolio bereit, das von der Public Cloud mit zusätzlichen Kontrollmechanismen über lokale Private-Cloud-Modelle bis hin zu national betriebenen Partner Clouds reicht.
Die entscheidende Aufgabe besteht darin, das passende Modell für die jeweilige Anforderung zu wählen. Dabei müssen Unternehmen nicht nur die Technologie vergleichen, sondern auch den Schutzbedarf, die regulatorischen Anforderungen, die Betriebsfähigkeit, die Innovationsziele und die Resilienz bewerten.
Eine Sovereign Public Cloud kann optimal sein, wenn Skalierbarkeit und Innovation im Vordergrund stehen. Eine Sovereign Private Cloud kann die richtige Wahl sein, wenn Autonomie, lokale Kontrolle und Offlinefähigkeit entscheidend sind. Eine National Partner Cloud ist besonders relevant für hochregulierte staatliche oder sicherheitskritische Szenarien.
Für Unternehmen ist digitale Souveränität damit kein statischer Zielzustand, sondern ein kontinuierlicher Gestaltungsprozess. Sie erfordert Architektur, Governance, Security, Betrieb, Compliance und organisatorische Reife. Ein Cloud Center of Excellence kann dabei helfen, diese Fähigkeiten zu bündeln und in konkrete, wiederholbare Umsetzungsmuster zu übersetzen.
Die zentrale Botschaft lautet: Microsoft bietet ein vielfältiges Portfolio, um souveräne Cloud-Lösungen zu integrieren. Welche Lösung die richtige Wahl ist, hängt vom jeweiligen Bedarf ab. Unternehmen sollten diese Entscheidung bewusst, strukturiert und mit erfahrenen Partnern treffen. Denn digitale Souveränität ist nicht das Gegenteil von Cloud, sondern die Voraussetzung dafür, Cloud langfristig sicher, kontrolliert und innovativ zu nutzen.